背景

源码分析类任务在连续多轮执行后，存在两类续跑不稳问题：

1. 普通续跑时，读时消息裁剪窗口过小，较早的 read_file 结果会在未触发 compact 前先被裁掉。
2. 命中 max_loops 退出时，runtime 直接报错结束，未先沉淀 durable TaskState + compact summary，导致后续输入“继续”时主要依赖最近消息窗口。

本次修改

• 新增 context.compact.read_time_max_message_spans 配置项，并提供默认值 24
• 将读时 trim 从硬编码窗口改为读取配置，缓解普通续跑时的上下文过早丢失
• 新增 compact mode loop_limit
• 在 runtime.Run() 命中 max_loops 前，best-effort 执行一次 loop_limit continuation checkpoint
• continuation checkpoint 成功时：
  • 回写 compact 后的 session.Messages
  • 回写 session.TaskState
  • 重置累计 token
  • 发出 compact_start / compact_done
  • 最终仍以可恢复错误结束当前 run
• continuation checkpoint 失败或 no-op 时，保持原有退出语义
• 补齐新配置项的序列化 / 反序列化 / 默认值 / 校验测试
• 补齐 loop_limit 成功与失败分支的 runtime 测试
• 更新配置与 compact 相关文档

影响

• “继续分析”场景下，文件读取结果更不容易在普通续跑中被过早裁掉
• 达到最大轮数后，后续续跑会优先依赖 durable checkpoint，而不是只依赖最近几条消息
• 不改变 auto_compact 默认关闭的现状
• 不修改 filesystem_read_file 的 micro compact 策略，行为面保持最小

验证

• go test ./internal/runtime
• go test ./internal/config ./internal/context
• go test ./...